-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Query endpoint #1643
base: main
Are you sure you want to change the base?
Query endpoint #1643
Conversation
Signed-off-by: Joe Lanford <[email protected]>
Signed-off-by: Joe Lanford <[email protected]>
Signed-off-by: Joe Lanford <[email protected]>
Signed-off-by: Joe Lanford <[email protected]>
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
1a96032
to
a27fada
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1643 +/- ##
==========================================
- Coverage 67.42% 63.97% -3.46%
==========================================
Files 55 57 +2
Lines 4632 4957 +325
==========================================
+ Hits 3123 3171 +48
- Misses 1284 1554 +270
- Partials 225 232 +7
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
@@ -0,0 +1,118 @@ | |||
package storage |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, we should discuss this. I added this because the http
package documentation recommended using http.ServeContent
over io.Copy
for a number of reasons, and http.ServeContent
needs an io.ReadSeeker
. The main benefit for us would be support for the Range
http headers.
I found this multiReadSeaker implementation in a Golang issue proposing that it be added to the standard library, so there may be license concerns. We may need to implement our own or look into implementing the range functionality another way.
17e0f9a
to
729645c
Compare
BaseContext: func(_ net.Listener) context.Context { | ||
return log.IntoContext(context.Background(), mgr.GetLogger().WithName("http.catalogs")) | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can either drop this whole BaseContext
or alternately, simply return l
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either way, I don't think the code uses the logger from the context. This was a holdover from the way that the original logging middleware worked.
// }, | ||
|
||
// by default the compressor will only trigger for files larger than 1400 bytes | ||
const testCompressableJSON = `{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If all this is stuff is to test the gzip handler in isolation, I think we can simplify.
If the goal is to test the entire stack of handlers, I figure there's a better way to organize and test to reduce duplication and fragility. For example, if we make the CatalogServerConfig
accept an arbitrary http.Handler
instead of a storage.Instance
, then we can:
- test the
storage.Instance
handler in isolation - test the
serverutil
setup with dummy handlers that are easier to manipulate for test purposes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or, the other relevant question is, do we need to test the gzip handler explicitly in our unit tests? We're importing "github.com/klauspost/compress/gzhttp"
to provided compressed content via our server. Are unit tests that say "tests if the library is doing its job" really that useful?
// { | ||
// name: "Ignores accept-encoding for the path /catalogs/test-catalog/api/v1/all with size < 1400 bytes", | ||
// setupStore: func() error { | ||
// return writeFile(filepath.Join(store.RootDir, "test-catalog2", "catalog.jsonl"), []byte(`{"foo":"bar"}`), 0600) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know existing tests violate this rule, but one thing I think I would fix is to avoid writing to the underlying filesystem, because it is pretty fragile. I think we can probably test as a black box, something like:
- Check
ContentExists(foo)
is false Store(foo)
- Query various endpoints with positive and negative tests for
foo
,bar
catalogs, but also just different path prefixes, etc. - Check
ContentExists(foo)
is true Delete(foo)
- Query
foo
endpoints and expect 404 - Check
ContentExists(foo)
is false.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, I've added this test in localdir_test.go
, and avoided writing directly to the file system (using store.Store
instead)
What's the relation of this PR to #1642? Which PR is a duplicate and which should be reviewed? |
729645c
to
478c152
Compare
@azych apologies for the confusion. You're just seeing the result of rapid experimentation. This is the one to review, but it's still a WIP. I've converted this PR to a draft. |
// } | ||
|
||
// // Verify index file was created | ||
// indexPath := filepath.Join(s.RootDir, "test-catalog", "index.json") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would avoid the hardcoded path because it is pretty fragile. Maybe use:
indexPath := catalogIndexFilePath(s.catalogDir("test-catalog"))
Description
Reviewer Checklist